[HZ-5434] FencedLock for Asyncio#818
Conversation
# Conflicts: # hazelcast/internal/asyncio_client.py
# Conflicts: # hazelcast/asyncio/__init__.py
# Conflicts: # hazelcast/asyncio/__init__.py
# Conflicts: # hazelcast/asyncio/__init__.py # hazelcast/internal/asyncio_proxy/cp_manager.py
# Conflicts: # hazelcast/asyncio/__init__.py # hazelcast/internal/asyncio_proxy/cp_manager.py
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #818 +/- ##
==========================================
- Coverage 94.17% 94.09% -0.08%
==========================================
Files 411 412 +1
Lines 27511 27684 +173
==========================================
+ Hits 25908 26049 +141
- Misses 1603 1635 +32 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
How are you going to protect lock ownership without thread id? There will be concurrent runs, right? |
The lock is reentrant for lock attempts with the same client, similar to the Node.js client, so data races will happen with operations that uses the same client. |
3 participants
Ported
FencedLockproxy to asyncio.The asyncore variant uses actual thread IDs to disable re-entrancy.
That's not useful with the asyncio variant, so currently the thread ID
0is used when necessary.I've omitted docs that refer to threads, and tests that use threads.
I'll push another PR to add those after lock context implementation.